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(54) Cable modem link layer bridge 

(57) A cable modem link layer bridge includes a 
downstream fonwarding task and an upstream forward- 
ing task The downstream forwarding task is stmctured 
to receive a first message from a cable network and for- 
ward the first message to a customer premises equip- 
ment (CPE). The upstream fonwarding task is structured 
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to receive a second message from the CPE and forward 
the second message to the cable network, the upstream 
and downstream forwarding tasks being multitasked 
such that the second message is fonwarded by the up- 
stream fonward task while the first message is being for- 
warded by the downstream fonwarding task. 
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Description 

[0001] Tlie present Invention relates to cable modems, and In particular, to a link layer bridge of a cable modem. 
[0002] Cable operators are interested in deploying high-speed data communications systems on cable television 

5 systems, in an effort to enable the definition, design, development and deployment of data-over-cable systems on an 
unifomi, consistent, open, non-proprietary, muiti-vendor Interoperable basis, the cable operators have prepared a se- 
ries of interface specifications known as Data-Over-Cabie Sen^lce Interface Specifications (DOCSIS). The intended 
service will allow transparent bi-directional transfer of Internet Protocol (IP) traffic, between the cable system of the 
cable operator and customer locations, over an all-coaxial or hybrid-fiber/coax (HFC) cable network. 

10 [0003] Figure 1 illustrates a communications system 10 envisioned by DOCSIS. The communications system 10 
includes a cable modem termination system (CMTS) 12 that interfaces with a wide-area network 14, such as the 
Internet. The CMTS 12 is coupled by a cable network 16 to a cable modem (CM) 18, which is coupled to a customer 
premises equipment (CPE) 20, such as a computer, by a CM-CPE interface 22. The CMTS 12 and cable modem 18 
provide a cable-based communication interface between the CPE 20 and the wide-area network 14, thereby allowing 

15 a user of the CPE 20 to send data to and receive data from the wide-area network 1 4. The advantages of such a cable- 
based communication system 10 is that the cable networtc 16 is already in place in most locations in the United States 
for television systems and the cable networtc 1 6 is capable of much faster data transmission rates than current systems 
employing public telephone lines. 

[0004] Although it specifies many basic requirements of the communication system 10, DOCSIS does not specify 
20 the details of how those requirement are implemented. For example, DOCSIS specifies (page 14) the following rules 
(among others) that the cable modem 18 must follow when exchanging data between the cable network 16 and the 
CPE 20, but does not specify the hardware and/or software to be used by the cable modem 18 to satisfy the rules. 

3.1.2.3.2 Forwarding 

25 

[0005] Cable modem (CM) forwarding In both directions MUST confomi to the following general 802.1 d guidelines: 

• Lrnk layerlrames between a given pair of end-stations MUST be delivered in order, 
o Link-layer frames MUST NOT be duplicated' - 
30 o stale frames (those that cannot be delivered in a timely fashion) MUST be discarded. 

[0006] An embodiment of the invention is directed to a cable modem link layer bridge that includes a downstream 
fonvarding task and an upstream fonwarding task. The downstream fonwarding task is structured to receive a first 
message from a cable network and fonward the first message to a customer premises equipment (CPE). The upstream 

35 forwarding task is stmctured to receive a second message from the CPE and fonward the second message to the cable 
network, the upstream and downstream forwarding tasks being multitasked such that the second message is forwarded 
by the upstream fonward task while the first message is being forwarded by the downstream forwarding task. 
[0007] Another embodiment of the Invention is directed to a cable modem link layer bridge that includes a station 
cache and a station cache manager. The station cache Includes a plurality of station entries, with each station entry 

40 being associated with a respective one of a plurality of customer premises equipment (CPE). The station entry includes 
a function Identifier that identifies an action to be taken by the bridge In response to receiving a message intended for 
the associated CPE. The station cache manager structured to modify the function identifier in response to a user 
request. 

[0008] Another embodiment of the Invention is directed to cable modem that includes a host for receiving messages 
45 directed to the cable modem; a first set of memory buffers for storing messages; a media access controller (MAC); a 
downstream forwarding task a second set of memory buffers; and a host receive task. The MAC is structured to receive 
a first message from a cable network and store the first message in a first memory buffer of the first set. The downstream 
fonwarding task Is structured to determine whether the first message Is directed to the host. The host receive task is 
stmctured to copy the first message into a second memory buffer of the second set, release the first memory buffer 
50 for re-use by the MAC, and pass control of the first message to the host for processing using the second memory buffer. 
[0009] Some embodiments of the invention will now be described by way of example and with reference to the 
accompanying drawings in which: 

[0010] Figure 1 is a block diagram of cable communication system employing a cable modem. 
[001 1] Figure 2 is a block diagram of a cable modem Including a link layer bridge according to the present Invention. 
55 [0012] Figures is a state diagram showing a method according to an embodiment of the present invention for process- 
ing downstream message frames received from a cable network. 

(001 3] Figu re 4 is a state diagram showing a method according to an embodiment of the present invention for process- 
ing upstream message frames being sent to a cable network. 
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[001 4] Figure 5 Is a state diagrarn showing a method according to an embodiment of the present invention for process- 
ing downstream message frames from a cable modem host to a customer premises equipment. 
[0015] Figures is a state diagram showing a method according to an embodimentofthe present invention for process- 
ing upstream message frames from a customer premises equipment to a cable modem host. 
5 [0016] Figure 7 is a blocl< diagram of memory management data structures for managing cable modem memory 
objects according to an embodiment of the present invention. 

[0017] Figure 8 is the blocl^ diagram of Figure 7 while obtaining a memory object from a memory object pool, 

[0018] Figure 9 is the block diagram of Figure 7 while returning a memory object to the memory object pool. 

[001 9] Figure 1 0 is a blocic diagram of data structures employed to implement a customer premises equipment (CPE) 

10 address table according to an embodiment of the present invention. 

[0020] Figure 1 shows a cable modem (CM) 50 according to an embodiment of the present invention. The cable 
modem 50 Includes a media access controller (CM MAC) 52, an Ethernet controller 54, a host 58, and a bridge 58. 
The CM MAC 52 is coupled to and Interfaces with the cable network 16 to transfer internet protocol (IP) frames or 
packets between the cable modem 50 and the cable network. The Ethernet controller 54 is coupled to and Interfaces 

IS with the CPE 20 to transfer IP frames between the cable modem 50 and the CPE. The Ethemet controller 54 includes 
an Ethemet port that can be coupled to a single CPE 20 or a set of plural CPEs. The host 56 allows the cable modem 
50 to communicate with other communications devices (e.g., other cable modems, telephone line modems, etc.) without 
requiring the computing facilities of the attached CPE 20. The cable modem 50 also includes a CM Manager 60 that 
controls the operation of the bridge 58 by setting certain configuration parameters during an Initialization phase or 

20 modifying those parameters as desired. The CM MAC 52, Ethernet controller 54, host 66, and bridge 58 are imple- 
mented in one embodiment using a software-controlled microprocessor, although those skilled in the art will understand 
that a hardware configuration could be implemented based on the discussion herein. 

[0021] The host 56 has its own unique Ethernet address which allows data frames to be received by the host. The 
host includes both a TCP/IP host or protocol stack that can receive and transmit I P frames and an LLC host or protocol 
25 Stack that can receive and transmit LLC frames. In one embodiment, the TCP/IP host is "Fusion" from Pacific Software 
Inc.. although other TCP/IP hosts could be employed. 

1.1 Bridge Functions 

30 [0022] The bridge 58 is the part of the cable modem 50 that transfers data traffic back. and forth between the CM 
MAC 52 interface and the Ethemet controller 54 interface. The bridge 58 operates at the data link layer level (Layer 
2): it receives Ethernet frames on one interface and retransmits the very same frame on the other interface. A software 
implementation is described below, although those skilled in the art will understand that the same functions could be 
implemented in hardware. 

35 [0023] The cable modem 50 supports the standard Ethernet frame format (DIX), as per RFC-894, and IEEE 802.3 
(with SNAP-Sub-Network Address Protocol framing), as per RFC-1042 frame fonnats. The IEEE 802.3 frame format 
is implemented for 802.2 LLC commands XID and TEST addressed to the CM host 56. 
. [0024] DOCSIS specifies a certain number of Ethemet MAC address-based filtering rules for downstream and up- 
stream directions; frames that do not confomi to these filtering rules must be discarded by the bridge. The most im- 

40 portent rule Is based on the "learning" principle: the bridge must not forward frames transmitted between two nodes 
located on the same side of the bridge, such as the traffte between the CM and the CMTS (both located on the cable 
side) or between two CPE's (on the Ethemet side). Such frames, therefore, are discarded. 

[0025] DOCSIS also requires filtering ability based on the Network Layer protocol embedded In the fonwarded Eth- 
emet frames. Filtering on IP (and ARP) or other Layers protocol (such as IPX, NetBIOS, and Appletalk) is Implemented, 
45 based on the Ethernet Type field value (for DIX framing) or the SNAP Ethemet Type (for 802.3 with SNAP framing). 
Filtering of IEEE 802.1 d BPDU (Bridge Protocol Data Unit) is also implemented. 

[0026] IP protocol filters (Layer 4) are also required by DOCSIS. The IP protocol filters can be used to restrict up- 
stream or downstream traffic based on source and destination IP addresses, transport-layer protocols (such as TCP, 
UDP» and ICMP). and source and destination TCP/UDP port numbers. 

50 

1.2 Downstream and Upstreanf Bridging Processes 

[0027] Two of the main processes of the bridge 58 are the downstream bridging (from CM MAC 52 to Ethemet 
controller 54) and the upstream bridging (from Ethernet controller to CM MAC). In a preferred embodiment of the 
55 present invention, these processes are implemented using separate tasks that are muttitasked by the bridge micro- 
processor 60 or by plural microprocessors. The term "task" is used herein in its known computer sense to refer to an 
Independent processing context memory structures that allows the task to be processed Independently from and si- 
multaneously with other tasks. 
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1^.1 Downstream Bridging Process 

[0028] A downstream bridging process according to an embodiment of the present invention is shown in Figure 3. 
The CM MAC 52 receives Ethernet frames from the cable network 1 6 and stores them in respective MAC memory 
5 buffers arranged In a downstream MAC queue 62. A downstream forward process 64 of the bridge 58 selects the next 
frame from the queue 62 and, based on the infomiation in a frame header of the frame (Destination address, Source 
address, Type), three possible actions can follow: 

1/ discard the frame (step 66), that is, release the memory buffer in which the frame was stored; 
10 21 fonward the frame to a transmit frame to CPE function 68 if the destination address of the frame matches an 

Ethernet address of one of a group of authorized CPEs that are coupled to the cable modem 50; or 
3/ pass the frame up to a local host receive function 70 if the destination address of the frame matches the Ethernet 
address assigned to the CM host 56. 

IS [0029] Upon receiving a frame from the downstream forwarding process 64, the transmit frame to CPE function 68 
passes the frame to an Ethernet controller transmit function 72 of the Ethernet controller 54, which passes the frame 
to the appropriate CPE 20. If the Ethemet controller transmit function 72 is cun-ently passing a previous frame to the 
CPE 20, then the Transmit frame to CPE function 68 attaches the memory buffer for the current frame to an Ethemet 
transmit queue 74. The Ethemet controller transmit function 72 talces frames from the Ethernet transmit queue 74 

20 according to a predetemnined order and forwards them to the CPE 20, Upon transmission of a frame to the CPE 20, 
the Ethemet controller transmit function 72 frees the memory buffer of the frame for re-use by the CM MAC 52 for a 
subsequent frame received by the CM MAC. 

[0030] Upon receiving a frame from the downstream fonwarding process 64, the local host receive function 70 de- 
termines from the frame header whether the frame is an IP frame or an LLC frame. If the frame is an IP frame, then 
25 the local host receive function 70 copies the frame Into a Fusion stack specific data structure ("message") and passes- 
the Fusion message to a Fusion TCP/IP host 56A. If the frame is an LLC frame, then the local host receive furiction 
70 fonwards the frame to an LLC host 66B. jn either case, the memory buffer of the frame is freed by the host 56A, 
56B upon completion of processing of the frame. . 

' 90. 1.2.2 Upstream Bridging Process ' ' - - 

[0031] An upstream bridging process according to an embodiment of the present Invention is shown in Figure 4. An 
Ethernet controller receive function 76 of the Ethemet controller 54 receives Ethemet frames from the CPE 20 and 
stores them in respective Ethernet receive buffers 78. A receive frame from CPE function 80 of the bridge 58 receives 
35 the frames from the Ethernet controller transmit function 76 and passes the frames to an upstream forwarding process 
82. The upstream forwarding process 82 reads the frame header of each frame and, based on the iiiformation in the 
frame header (Destination address, Source address. Type), two possible actions can follow: 

1/ Discard the frame (step 84), that Is, release the Ethemet receive buffer; or 
40 2J Fonward the frame to the CM MAC 52 by placing the Ethemet receive buffer into an upstream MAC queue 86. 

The CM MAC 52 transmits frames In sequential order from the upstream MAC queue and releases the Ethemet 
receive buffers of the transmitted frames for re-use by the Ethemet controller receive function. 

1 .2.3 CM Upstream Tlransmisslon Process 

45 

[0032] Figure 4 also illustrates a cable modem upstream transmission process for frames generated by the CM hosts 
56A, 56B for transmission to the cable networic 1 6. A local host transmit function 88 receives frames In memory buffers 
from the CM hosts 56A, 568 and places them into the upstream MAC queue 86. The CM MAC 52 transmits the frames 
from the upstream MAC queue 86 to the cable network 16 and frees the memory buffers for re-use by the CM hosts 
50 66A, 56B. 

1.3 CiVi/CPE Downstream Bridging 

[0033] A CM/CPE downstream bridging process according to an embodiment of the present invention is shown in 
55 Figure 5. A local host transmit function 88 receives frames in memory buffers from the CM hosts 56A, 56B and passes 
them to the transmit frame to CPE function 68. Upon receiving a frame from one of the CM hosts 56A, 56B, the transmit 
frame to CPE function 68 passes the frame to the Ethemet controller transmit function 72 of the Ethemet controller 
54, which passes the frame to the appropriate CPE 20. if the Ethernet controller transmit function 72 is currently passing 
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a previous frame to the CPE 20, then the Transmit frame to CPE function 68 attaches the memory buffer for the current 
frame to the Ethernet transmit queue 74. The Ethemet controller transmit function 72 takes frames from the Ethernet 
transmit queue 74 according to a predetermined order and forwards them to the CPE 20. Upon transmission of a frame 
to the CPE 20, the Ethemet controller transmit function 72 frees the memory buffer of the frame for re-use by the CM 
5 hosts 56A, 56B. 

1^ CPE/CM Upstream Bridging 

[0034] A CPE/CM upstream bridging process according to an embodiment of the present invention Is shown in Figure 
10 6. The Ethemet controller receive function 76 of the Ethemet controller 54 receives Ethernet frames from the CPE 20 
and stores them in respective Ethemet receive buffers 78. The receive frame from CPE function 80 of the bridge 58 
receives the frames from the Ethernet controller transmit function 76 and passes the frames to the local host receive 
function 70. 

[0035] Upon receiving a frame from the receive frame from CPE function 80, the local host receive function 70 
15 determines from the frame header whether the frame is an IP frame or an LLC frame. If the frame Is an IP frame, then 
the local host receive function 70 copies the frame into a Fusion message and passes the Fusion message to the 
Fusion TCP/IP host 56A. If the frame Is an LLC frame, then the local host receive function 70 fonwards the frame to 
the LLC host 56B. In either case, the memory buffer of the frame is freed by the host 56A, 56B upon completion of 
processing of the frame, 

20 

1 .3 Forwarding Rules 

[0036] Forwarding mies are based on Data Linic Layer (Layer 2) as well as Network Layer (Layer 3) and Transport 
Layer (Layer 4), if enabled. Layer 2 rules are based on: 

25 ■ 

o Ethernet Source Address 

• Ethernet-Destination Address: Unleash Broadcast or iVlulticasL ... / - 

[0037] Layer 3 rules (LLC protocol fitters) are based on Ethernet Type value (such as 0x800 tor iP. 0x806 for;ARP, ; 
30 etc.). The Ethernet Type is found right after the Source Address for DIX framing and.&t the end of the SNAP header 
for 802.3-SNAP framing. Layer 4 rules (IP protocol filters) apply for IP traffic and are based on protocol type (ICMP, 
IGMP, TCP or UDP) and UDP/TCP port number. 

[0038] The bridge 58 implements the forwarding rules described hereafter. 

35 Downstream Forwarding rules 

[0039] The Layer 2 downstream fonvarding rules implemented by the bridge 58 are as follows: 

o State frames (those that can not be delivered in a timely fashion) must be discarded: this rule is Implemented by 
40 enforcing a maximum number of frames waiting in the Ethemet Transmit Queue 74. If that maximum is reached, 

Indicating congestion on the Ethernet port, the frame is discarded, 
o Broadcast Ethemet frames (Destination Address = FF:FF:FF:FF:FF:FF) must be fonvarded BOTH to the Ethemet 

CPE port AND to the CM IP host 
o l^ultlcast Ethemet frames (Group bit of Destination Address set to 1 ) must be forwarded to the Ethernet CPE port. 
43 However, all MAC Management frames (Destination Address = 01 :E0:2F:00:00:xx) must be discarded. 

o Unicast frames addressed to unknown destinations (Destination Address NOT found in the CPE table) must be 
discarded; if the address is found in the CPE table, the frame must be fonvarded to the Ethernet CPE port. 

[0040] Once l-ayer 2 filtering is complete, the frame Is still subject, if enabled, to Layer 3 and Layer 4 filtering. 

50 

1^.2 Upstream Forwarding Rules 

[0041] The Layer 2 upstream fonwarding rules implemented in the present bridge design are as follows: 

55 o State frames (those that can not be delivered in a timely fashion) must be discarded: this rule is implemented by 
setting a maximum number of messages in the upstream MAC queue 86. If that maximum is reached, indicating 
congestion on the Cable port, the Ethemet Receive process discards Incoming frames. 

• Broadcast Ethemet frames (Destination Address = FF:FF:FF:FF:FF:FF) must be fonwarded to the Cable CPE port. 
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• Multicast Ethernet frames (Group bit of Destination Address set to 1) must be forwarded to the Ciy^ MAC port. 
However, all BPDU (Bridge Protocol Data Unit) frames (Destination Address = 01:80:C2:00:00:xx) must be dis- 
carded. 

• Unlcast frames from source addresses other than those provisioned or learned as supported CPE devices (Source 
5 Address NOT found in the CPE table (discussed below) or NOT marked as supported CPE) must be discarded. 

If the address is found In the CPE table, and If and only if it is marked as a supported CPE device should the frame 
be forwarded to the CM MAC 52. However, if the Destination Address is also a CPE device (Destination Address 
found in the CPE table), the frame must be discarded as in a traditional learning bridge. 

10 [0042] Once Layer 2 filtering is complete, the frame Is still subject, If enabled, to Layer 3 and Layer 4 filtering. 

3 Bridge Data Structures 

[0043] The bridge 58 will essentially handle two flows of data: 

IS 

» Traffic between the CM MAC 52 and the Ethernet controller 54. This is a high volume, low latency traffic. The 
frames can (and will) use up to the 1500 bytes Ethernet size limit, but their contents will not change and therefore 
they can be handled very quickly once the decision to forward or not is taken. 

• Traffic between the local CM IP host and either the CM MAC 52 orthe Ethernet controller 54. This is a much lower 
20 volume, higher latency traffic. Even with VoIP, this traffic is in the order of 1 0-20 bytes every 1 0 ms (plus IP & UDP 

headers) per channel. However these frames need to go all the way up the IP protocol stack and their buffers 
cannot be relinquished quickly to the CM MAC 52. On top of that, the Fusion IP stack has already its own type of 
data structures: the "message" (struct m). 

25 [0044] To cope with these constraints, the bridge 58 uses simple fixed pools of memory buffers for frames coming 
1.. from the CM MAC 52 and for frames cbming from the Ethernet controller 64. The frames to and from the TCP/IP host . 

vivs.. 56A are copied to and from the Fusion message structures. 

. 3:1Gteneral DOCSIS Bridge Data Structures 

v-i-t.'.-.- ■ • :.:30- . ■ .. .; ■ " ■ ■ : ■ ■ "• . 

• [0045] Each uiterface, the CM MAC 52 and the Ethernet controller 54, will maintain a separate pool of fixed buffers 
for received frames on their respective sides. The bridge 58 Is responsible to release the buffers It gets from the CM 
MAC 52 once the frame has been successfully transmitted on the Ethernet port or discarded. The CM MAC 52 is 
responsible for releasing the buffers it gets from the bridge 58, once the upstream channel transmission is complete. 
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3.1.1 Abbreviations used in data structures 





[0046] 




40 


Buff 


Buffer 




Dwstr 


Downstream 




Upstr 


Upstream 




Fwd 


Forward 




Ether 


Ethernet 


45 


Len 


Length 




Max 


Maximum 




MIn 


Minimum 




Hdr 


Header 




Msg 


Message 


50 


Ptr 


Pointer 




Tx 


Transmit 




Rx 


Receive 




Sem 


Semaphore 
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3.1 .2 General Bridge Data Structures Definition 
[0047] 

5 

Mefine u8 unsigned char /* 8 bits on ST20 cc V 
ikiefine ul6 unsigned short /* 16 hits on ST20 cc */ 
10 ftdejine u32 unsigned int 32 bits on ST20 cc,V 



Mefine boolean int 

15 

ikiefine true 1 
Mefine fixlse 0 

20 [0048] Note: The "canonical" maximum Ethernet frame size (as defined in the original DIX specifications) is 1518 
bytes, including the Ethernet header (14 bytes), the maximum payload size (1500 bytes) and the 4-byte CRC. 
[0049] The 48-bit Ethemet IVIAC address type is defined as follows: 

typedef u8 a48[6]; r Ethernet Address (6 bytes) V 
[0050] We also define the Ethernet header we must find at the beginning of an Ethemet frame: 

25 

typedef Struct ether _hdr { 

u8 ether jihost [6]; /* Pestiriation Address (6 bytes)"^/ 
^ u8 ether jshost[6]: Source Address (6 bytes) 

ul6 ether jype: /* Ethemet Type (2 bytes) V 
} ether Jidr; 

35 

[0051] As a placeholder for all the Bridge control variables, we define the Bridge Control Structure as follows: 



40 



45 



50 



55 



typedef Struct BridgeCa { 

boolean Bridge JUp; /* true if bridge i//7 and running V 

boolean ForwardingJSnabled: /* true if forwarding enabled V 
int Max_SupportedJ2PE; /* Maximum number of siq>ported 

CPE set by CM Manager */ 
ira SupportedjCPE; /♦ Total number of supported CPE ♦/ 

int Learned JCPE; /♦ Total number of learned CPE */ 

; BridgeCtl; 

BridgeCtl BridgeControl; /* Define one control structure */ 

[0052] The different members of that structure are detailed below. 
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3.1 .3 Memory ObJ cts Manag m nt 

[0053] To manage data structures such as buffers used by the forwarding processes, the bridge 58 employs a flexible 
mechanism able to provide upon request a data structure of the desired type and recycle them once the object (the 
5 data structure in this case) is not needed anymore, as shown in Figures 7-9. As used herein , the temn "memory object" 
refers to data structures or collections of such structures stored in the processor's memory, either by static or dynamic 
memory allocation. However, the management system described herein Is applicable to any kind of memory objects. 
[0054] This mechanism accommodates several pools of different types of memory objects and different numbers of 
such memory objects in each of them. The memory management mechanism: 

10 

o manages memory objects of different types and sizes; 
o supports any number of memory objects in each pool; and 

o functions logically as a stack, that is, gets an object from a pool, then retums the object to it. 

15 [0055] Each pool is implemented as an array 90 of the maximum number of the memory objects 92. The pool can 
be defined as ObjectType ObJectsfSize];. 

[0056] For instance, the Downstream Fonvarding Buffers pool is declared as follows: 

^ Static Dwstrjidr Dwstr_Buffjirray[MAXJOWSTR]; 

/* Downstream Bvffers Array */ 



25 [0057] Where ''MAX_DWSTR" is the maximum number of such buffers we want to create. Note that the number of 
memory objects can be different for each pool. Also note that, although the memory is statically allocated In the present 
exanriple. this method is valid for dynamicalty allocated memory as well. 

[0058] . SJnj?e.each entry is a data structure, copying it back and forth is not desirabje, especially for large data buffers. . 
In order to access these entries, the bridge 58 uses a collectiph of as many pointers 94 as there are objects in the ■.. 
30 pool, iogicaily organized as a stack 96. Each stack 96 is an array of pojnters 94 where each pointer references a single 
object 92 in the pool and is defined as: 

void *Pointer_Stack[S/ze]; 
[0059] To bridge 58 defines the downstream buffers pointer stack as: 

35 

static void ^Dwstr_Ptr_StackfMAX_DWSTRJ; 

Downstream Btiffers Pointers Stack V 

40 [0060] Since the pointers are of type void, they can point to any type of memory objects. The stack operation Is 
controlled through a stack control structure 98: 

typedef struct Stack J 



int top; points to next available entry V 

int size; /** number of elements in the pool V 

50 

void ^"^erOry; /* points to the pointer array V 
} Stack J; 

55 [0061] The top field is an index pointing to the next available pointer In the stack (like a stack pointer). The size field 
indteates how many objects this pool manages (can vary from one pool to another, according to each task need). The 
enfry field is a pointer to the first element of the array of void pointers. 

[0062] This system allows a stack-like management of pools of objects of any type and of any quantity, through a 
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universal control structure type (Stack_J). 

[0063] Two universal API's allow the bridge 58 to retrieve an object fronn the pool and to return the object to it: 

void '^GetjObjectfStackJ "^sj; /* Get new object from stack V 

void RetumJDbject (void "^object. Stack J ^s); 
/* Return an object back to stack V 



10 



[0064] Once again, using void pointers allows accommodating any type of objects. 

[0065] To get an object from the pool as shown in Figure 8, the pointer located at the present index value of the top 
field Is returned; the top field Is post-Incremented, if the fopf leld reaches the s/zefield value, a NULL pointer is returned 
instead, indicating that the stack has been emptied. 
IS [0066] To return an object to the stack as shown in Figure 9. the fop field is predecremented and the pointer value 
is written to the pointer array 96 at the new index value of the top field. 

[0067] To Initialize a stack, each pointer in the pointer array Is initialized to point to one memory object In the object 
array. The fields of the stack control structure 98 are also initialized appropriately; note that the size and entry fields 
remain constant throughout the stack operation, the top field Is initialized to 0. 
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3.1.4 Enumeration Types Definitions 

[0068] In order to support the incoming frames sorting and filtering process, the following enum types are also defined: 

' enum Eth_Frame_Type { 



Broadcast .= 1,, . /* Ethernet Brdixdcgst Frame */ 



W^^'. 30 " Multicast; V Multicast fr^ 

Unicast, /* Unicqst frame not ctddressed to CM */ 

UnicastjCMJIost /* Matches CM's own MAC address */ 
35 }; /* Set by examining Ethernet frame Destination Address */ 

enum FwdJ>ecision ( 

Discard = 1, /* Discard the frame */ 

CMJIost, Z'^' Forward to the CM local IP Host "^Z 

Ethemet^Port, /* Forward to the CPE Ethernet port V 

DOCSlS_Port, /* Forward to the RF Cable port */ 

45 

}; returned by forwardinj^ rules V 

3^ CM MAC and Ethernet Controller Data Structures 

so 3.2.1 CIM MAC to Bridge Downstream Data structures 

[0069] In the downstream direction, the buffer received from the CM MAC 52 actually contains the full CM MAC 
frame, starting with the DOCSIS header Before passing the frame to the bridge 58, the CM MAC software will overwrite 
the first 6 bytes of the DOCSIS header in order to include the following Infomiation: 



55 



A pointer to the beginning of the Ethernet frame itself (4 bytes). 
Length of the Ethernet frame (2 bytes). 
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[0070] Because the DOCSIS header is of variable length, the bridge 58 uses the pointer to know where the Ethernet 
frame effectively begins inside the buffer. Once the buffer is not needed anymore (silent discard, transmission overthe 
Ethemet port, copy to the Fusion IP stack), it is returned back to the downstream buffer pool. 

5 Data Structures Definitions: 

[0071] The buffer we get from CM MAC 52 begins with a specific header prepared by a downstream MAC driver in 
the CM MAC, ovenwriting the originally received CM MAC Header. This header contains infomiation about the Ethemet 
frame beginning and length: 

10 

Mefine MAX J3WSTRJLEN 1800 nuxximum length of DOCSIS frame V 
typedef struct Dwstrjtdr { 

u8 "^EtherJPtr; /* effective sUa^ of frame */ 

ul6 EtherJLen; Ethemet frame length */ 

u8 PDU_Buff[MAX_DWSTRJLEN]; /* Data buffer </ 

20 

Stack J ^stack /* Buffer stadt this bvffer comes from */ 
} Dwstrjtdr: 

25 [0072] T|).e bridge maintains a pool of such Downstream buffers, using the stack based management system 
described above: 

StdckJ Dwstr_Pdol; 

/* Downstream Buffers Pool Control Structure V 
static void '^DwstrJ'tr JStackfMAXJ^WSTRJ; 
/* Downstream Buffers Pointers Stack */ 
static Dwstrjtdr Dwstr_Buff_Arrc^(MAXJ)WSTR]; 
/* Downstream Buffers Arr{xy V 

40 [0073] If the downstream Buffer must be transmitted over the Ethemet interface, the pointer to that buffer is trans- 
mitted to the Ethemet controller transmit process using the Ethemet Transmission Queue that provides both a queuing 
mechanism for outbound Ethemet frames and a synchronization mechanism between the Downstream Forwarding 
task 64 and the Ethernet Controller ISR (Interrupt Service Routine). 

45 

messagejjueue ^Dwstr Fw d Q ueue— ADwstr Fwd Queue Struct; 
/* Downstream Forwarding Message Queue V 

so 

[0074] Each message contains a pointer to a Downstream MAC Buffer. The total number of messages in the queue 
provides a flow control mechanism for the downstream traffic: if there is no more empty message available, indicating 
a congestion of the Ethemet network on the CPE side, newly arrived frames are dropped instead of being queued, 

S5 3^.2 Bridge to DOCSIS Upstream data structures 

[0075] In the upstream direction, the bridge 58-will maintain a pool of fixed size Ethemet receive buffers 78 dedteated 
for the upstream-bridged traffic. 
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[0076] Data Structures Definitions: 

[0077] The buffers used for Upstream forwarding are defined as follows: 

iMeflne MAX^ETHER 1600 /* maximum length of Ethernet frame */ 
#define MAX_MSG 10 /* start with a pool of 10 buffers ♦/ 
Mefine MSG^IZE (MAX_ETHER + sizeoffint) *2) 
/* max Ethernet frame size + 2 words */ 



typedef struct Upstrjidr { 

intlen: /* frame length*/. 

int service; /* Service type for CM MAC */ 

char frame[MAX_ETHER]; /* Ethernet frame ♦/ 

Stack J *stack; /* Buffer stack this buffer comes from */ 
} Upstrjuir; 

[0078] The Upstream Buffer pool 78 will be implemented using the stack based management system described 
before: 

/^r Stackj Upstr_Bri_Pool; " 

Upstream Bridging Buffer s l^ool Control Structure, y 
static void *Upstr_Bri_Ptr_Stack[MAX_BRIJJPSTR]; 
/* Upstream Bridging Buffers Pointers Stack V 
static Upstrjidr Upstr_Bri_Buffjirray[MAX_BRIJJPSTR]; 
/♦ Upstream Bridging Buffers Array */ 



[0079] Note that a similar but separate buffer pool is implemented for the CM Local IHost as discussed below in 
Section 4.2.2. 

[0080] To queue each Upstream Buffer from the Ethemet receive ISR to the Upstream Forwarding task, an Upstream 
Message queue is implemented: 

messagejjueue *Upstr_FwdJ2^ue- &Upstr Fwd Queue Struct: 
/♦ Upstream Forwarding Message Qyeue, */ . 

3.2.3 CPE MAC Address Table 

[0081] The cable modem 50 maintains a table 100 of Ethemet MAC addresses of CPE devices connected to the 
cable modem. This table 100 Is filled by either CM provisioning (stored into NV RAM, or set through a configuration 
file), or learning (by listening to the Ethernet port, and taking note of the Ethernet source address). 
[0082] The CM 50 is set to support frames fonnrarding for up to a maximum number of CPE devices (device-depend- 
ent, or set by CMTS). However, it is necessary to keep track of other CPE devices connected to the Ethemet port, 
even though they are not taking part in the forwarding process, in order to filter out traffic between two CPE's. 
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[0083] Each CPE device information will be stored into a record as follows: 

typedef struct MACjuMt { 

. a48 €iddress: MAC address for this entry V 

uB supported; /* Boolean: 1 = TRUE, 0 = FALSE V 

u8 provisioned; /* i = provisioned, 0 = learned */ 

u8 forwarding; /^Forwarding instructions for this entry */ 



}MAC_addr; 

15 [0084] The supported V\q\6 Indicates whether that particular CPE is supported by the cable modem (i.e. the CM will 
forward its traffic bacic and forth). If the CPE is not supported, then all frames to and from that CPE will be discarded 
by the bridge 58. The provisioned field Indicates whether that particular CPE has been provisioned by the CM (from 
the downloaded configuration file or through SNMP) or It has been learned by listening to the CPE port; it is only 
relevant when supported Is true. 
20 [0085] The forwarding Held indicates how frarhes are to be fonA/arded to and from the CPE associated with the entry. 
For example, the fonvarding field can indicate that only http-type frames, TCP/IP frames, LLC frames, no frames, or 
all types of frames should be forwarded to and from the associated CPE. The CM manager 59 is programmed to set 
or change the value of the forwarding field as instructed by frames received from the cable system operator via the 
cable network 1 6, CM MAC 52, and bridge 58. It is envisioned that the level of sen/ice specified by the forwarding field 
. 25 will depend on the fees paid to the cable operator by the user of the associated CPE. 

[0086] Since the table needs to be searched at least once for each incoming frame from the DOCSIS Cable port as 
well as.from the Ethernet port, the bridge employs a fast and efficient method to search the CPE MAC address table 
100. For that reason, the CPE MAC address table is im^ 

[0087] To achieve a maximum spread of ihidibes, the hashing function used by the bridge 58; combines the (ast3 
30 bytes of the Ethernet address: the first 3 bytes being assigned to the rrianufacturer by. the IEEE (e.g; for STfi^icroelec- 

tronics: 00:80:el:xx:xx:xx ). Also to maximize the spread, the table size Is chosen as a prime number. 
^define Hash(addr) (((addr[5])-h(addr[4]) +(addr[3]))%HASHSiZE) 

[0088] Note: Several hashing functions can be simulated and tested on a large number of random addresses to 

check which one produces the best spread of indices. One embodiment of the bridge 58 uses the function defined 
35 above. 

[0089] Since the hashing function can produce the same key for different addresses, each hash table entry 1 04 can 
contain several records. Hence, each hash table entry 104 will be a null terminated linked list of one or more nodes 
106. A first node 1 06 of each linked list points to either a null value or to the first CPE table entry ^MAC.adtfr record). 
Each subsequent node of the linked list Includes a subsequent CPE table entry and a pointer to the next record or the 
40 null value. 

typedef struct ListNodef /* List Node with a link to "next" */ 
45 htAC _addr entry; /* CPE MAC address record */ 

struct ListNode ^next; 
} ListNode; 

50 
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typedef struct List(/^ Define a linked list ofListNode" */ 
int count; /* Number of nocks in the list */ 
ListNode ^head; /* Pointer to first node (hecu^ */ 

; List; 

Mefine HASHSIZE 37 Siz^joffuahing table (prime number) V 
typedef List HashTable[HASHSIZEJ; . .^^ . 
Define Hash table as an array of linked lists ^/ 
15 HashTable CPEJTable; /* CPE MAC Address Table */ 

[0090] To ensure that enough list nodes 106 entries are available, a pool of "MAX.CPE" list nodes 106 is created, 
using the stack based mechanism described before, from which we will draw a new entry each time we need to add 
one to the CPE table 100. 



20 



static Stack J CPEJPool; 
/« Create a stack of^'MAXJZPE" ListNode's 
^5 static void "^CPE^PtrJStackfMAXjCPEJ; 

. , . ..^r; Stack of pointers to ListNode elements V 

- staHc ListNode L^^^ 

Array of list nodes, iniiiali^d to OV .. . . 



30 



[0091] The bridge 58 will need to "pop" a pointer from the stacl<, and use the "ListNode" structure It Is pointing to, 
each time a new CPE Is either provisioned from theTFTP Configuration file or learned by listening to the Ethernet port. 
35 The Bridge will need to "push" a pointer baclc to the staci<, thus releasing the "ListNode" structure it is pointing to, in 
the case of a CPE being provisioned after the maximum number of CPE's has been reached: the bridge will have to 
lookup the CPE table for a CPE that has been learned and remove It, since provisioned addresses must take preference 
over learned addresses. 

[0092] Since at least two tasks, namely the downstream and upstream fonwarding processes 64. 82, can access the 
40 CPE table 1 00, the bridge 58 Implements an access synchronization mechanism to that common resource. The access 
synchronization mechanism is a mutual exclusion semaphore (mutex): 



45 



50 



oswjnutexj CPEJTableJSem; /* CPE Table Access Semcphore */ 

[0093] The first task wanting to access the table will "wait " on the mutex, but since the mutex is free, the first task 
will obtain access. If a second task wants to access the same CPE table 1 00 immediately after that, it will have to wait 
until the first task has released the mutex once finished accessing the table. 

3.3 CM MAC / CM IP Host Data Structures 

3.3.1 Fusion Inbound Receive Data Structures 

55 [0094] Downstream frames for the CM IP host 56A are received on a pool of buffers managed by the CM IP host 
receive process 70. Once a downstream frame is detemnined to be intended for the local CM IP host 56A, by matching 
its Ethemet destination address with the CM MAC address, the CM IP host receive process 70 will obtain a Fusion 
message ("m" buffer) from the Fusion heap by invoking the function lwq_gett)uf() and copying the frame contents Into 
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it. The Fusion message (m) structure is defined in the Fusion header fiie: m.h 

[0095] The CM IP host receive process 70 is running in a different task context than the downstream fonvarding tasic 
64. A message queue is used by the downstream forwarding tasIc 64 to pass the received Downstream Buffer address 
to the CM iP host receive tasIc 70. 

message _gueue Fusion RX Queue; 

/* Fusion Receive Task message queue */ 

3^.2 Fusion Outbound Transmit Data Structures 

[0096] Outbound frames from the Fusion IP stack 56A come within Fusion messages (m stmctures). The bridge 
specific send routine (bridge_start()) will copy the message contents Into an Upstream buffer from a dedicated buffer 
pool, then invoke the CM MAC upstream send API (docsisdrv_SendPdu() ). The Fusion Upstream buffer pool is defined 
as follows: 

Static Stack J UpstrjCMJPool; 
/* Upstream Fusion Buffers Pool Control Structure V 
static void ^Upstr_CMJ>trJStackfMAXJOMJ/PSTRJ; 
/* Upstream Fusion Buffers Pointers Stack */ 
static Upstrjidr UpstrSM^BuffjlrrayiMAXJZMJJPSTR]; 
^^v?.;; & Upstream Fusion Buffers Array V 

[0097] When retuming to hdq_start(), the function wiii release the Fusion message back to the Fusion heap 

(m_dispfn). 

[0098] If no upstream buffer is available, the bridge_startO function will return without sending the frame; the outbound 
datagram is therefore lost. Retransmission of UDP datagrams is the responsibility of the UDP based application. 

3.4 Bridge / Cable Modem Manager Data Structures 

[0099] The Cable Modem Manager interface with the Bridge is performed through the Bridge Control Stmcture: 

typedef struct BridgeCtl { 

boolean Bridge JUp; /* true if bridge up and running */ 
boolean Forwarding_Enabled; /* true if forwarding enabled */ 
int MaxJSupportedjCPE; /* Maximum number of supported 
CPE set by CM Manager V 

int SupportedJZPE; /* Total number of supported CPE V 
int LeamedJOPE: /* Total number of learned CPE */ 
} BridgeCtl; 

BridgeCtl BridgeControl; /* Define one control structure V 
[0100] The bridge 58 is not allowed to start data transfer between CM MAC 52 and the CM IP host 56A until the 
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Bridge_^Up flag is set to "true". This fiag can be set or reset eitiier by the Cable l\4odem Manager, using the appropriate 
API, or by the CM IP host 56A, when calling the bndge_updownO function. 

[0101] The bridge 58 does not start Downstream and Upstream forwarding processes until instructed to do so by 
the Cable Modem Manager by setting the Forwarding_Enabledt\ag. The Forwarding_Enabfed1\ag is set to false by 
s default. The Cable Modem Manager will eventually set it to true after successful registration. 

[0102] The maximum number of CPE's supported by the bridge 58 Is fixed to MAX_CPE. However, the number of 
effectively supported CPE's (lower than max) is kept in the Max_Supported_CPE variable whose value can be set by 
the Cable Modem Manager following the parsing of the CM Configuration file. The Supported_CPE and Leamed_CPE 
variables keep track of the number of supported and learned (as opposed to provisioned) CPE's, respectively. 

10 

4 Bridge Application Programming Interfaces (API's) 

4.1 Bridge Interface with CM MAC 

IS 4.1 .1 Downstream Bridge / MAC Interface 

[0103] The bridge 58 communicates with the CM MAC 52 by application programming interfaces (API's) defined 
below. In the downstream direction, the bridge 58 provides a buffer to the CM MAC (from the Downstream Buffer pool) 
and invokes the CM MAC receive API: 

20 

DwstrJBuffer = GetJ)bject(&Dwstr_Pool); 

•Dwstrjsrror = docsisdrvJ[tecvPdu( (unsigned char ^)DvfstrJSuffer, 
CM)MAXJiWSTkJJEN); 

[0104] Thiig: blocking API cal! will return only upon =a CM MAfr.frarne reception, successful or unsuccessfuL .The ^ 
downstreahi forwarding process will be.pehdihg bh- this API caH and process the received CM MAC frame. 

4.1.2 Upstream Bridge/ MACInterf ace . 

[0105] In the upstream direction, the API to the Upstream CM MAC contains three pieces of information: 

35 o Length of Ethernet payload; 

o Service # (used by CM MAC to compute the SID); and 
• The upstream Ethernet frame itself. 

[0106] The Ethernet Controller receive Interrupt service routine (ISR) will allocate a buffer of type Upstr_Hdr from 
40 the Upstream Forwarding Buffer pool and fill it out with the contents of the Ethernet frame. The Upstream forwarding 
task 82 will add, if the frame is to be forwarded, the length of the Ethernet frame and the service type. The frame is 
passed to the CM MAC 52 through this API: 



Upstr_error — docsisdrv_SendPdu( ServiceJType, 

Upstr_Buff'>Jrame, 

Upstr_Buff->len); 

so 

[0107] Until further clarification, the service type field will be set to 0. 

[0108] Although the upstream traffic from the cable modem IP host 56A, 56B could be passed to the CM MAC 52 
using the very same Buffer pool, It was decided to use an identical but separate Buffer pool (Upstr_CM_Pool) with an 
Identical buffer format (Upstr_hdr) for that purpose. That prevents the higher priority upstream bridged traffic from 
ss potentially "starving" the CM IP host 56A, 568 by consuming all the available buffers. The CM MAC upstream trans- 
mission API can be invoked by both the Upstream Forwarding process and the Fusion send routine. The CM MAC 
driver is responsible for copying the Upstream buffers to Its own queue and handling the possible reentrancy situations. 
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4^ Bridge Interface with FusI n IP Stack 
4.2.1 Fusion Downstream Receive Interface 



15 



20 



[0109] The Fusion IP stack 56A will receive Ethernet frames, that match the CM MAC address, from the Downstream 
fonvarding task 64. Once a downstream frame is routed to the local Fusion IP stack 56A, the local host receive process 
70 will get a Fusion message of the appropriate size from the Fusion heap by calling the function iwq_getbufO and 
copy the frame contents into the message buffer (pointed to by mp'>m_hp). If no Fusion message is available from 
the Fusion heap, the frame is discarded. In either case, the Downstream buffer is returned to the Downstream Buffer 
pool and the incoming message is queued into the Fusion's bridge device receive queue (iq_in()). 
[0110J The whole local host receive process 70, activated by the API call lwq_recv_task() runs in a different task 
context (local host receive task) than the downstream forwarding task (see section 5.1). The local host receive task 
70 is activated by the Downstream Fonwarding process 64 sending a message on the Fusion receive message queue: 
Fusion_RX_Queue. Fusion LWQ queuing routines (Iwq.c) are enabled (compile option: LWQ) 

4.2.2 Fusion Upstream Transmit Interface 

[Oil 1] In the upstream direction, the bridge 58 is seen as a Fusion network link layer device and therefore has an 
entry in the Network Device Table (ndevswO) with the following values (see Fusion Porting Guide. Chapter 5): 



nd_name = "DOCSIS Bridge" 

ndjladdr = {AF^ETHER} Ethernet-like Link Layer 



nd_updown 
nd_send 
nd^tart 
nd ioctl 



• bridgerjnit^ . 
' bridge jdpdown 

enjscomm 
■ bridge ^tart 

bridgejoctl, . 



Bridge init function 
Bridge up/down Junction 
Standard Ethernet send Junction 
Bridge start Ethernet Tx Junction 
Bridge control Junction 



[0112] The Fusion Device Transmission queue(ncLx/r)/fq) Is disabled (compiler option: NO_TRANSMIT_0) since 
the bridge upstream fon<varding process 82implements Its own upstream message queue 86. In order to transmit a 
40 frame upstream, the Fusion IP stack 56A will call its standard Ethemet send function (en_scomm()), where the Ethernet 
header is pre-pended to the outgoing IP packet. The next function called (ndq^startQ) will dereference the nd_start 
pointer in the ndevsiv structure In order to call the bridge-specific send routine: 
bridge_start(). 

[0113] The bridge-specific send routine (bridge_start()) will copy the message contents into an Upstream message 
45 buffer from the Fusion Upstream buffer pool, and invoke the CM MAC upstream API (docsisdrv^SendPduQ) with length 
and service type. When returned to, the ndq^startQ function will release the Fusion message back to the Fusion heap 
(mjdispfn): see ndq__startO in m.c. 



4.3 Bridge Interface with Cable Modem Manager 

50 

[0114] The Cable Modem Manager is a portion of the cable modem 50 that controls the operation of the bridge by 
setting a certain number of parameters, especially during the IP connectivity phase. Also, the configuration file down- 
loaded through TFTP may contain some bridge-related parameters such as the maximum number of CPE's and CPE 
MAC addresses to provision Into the CPE Table 100. The CM Manager interfaces with the bridge 58 through the 
S5 following set of three API's. 
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4.3.1 Initializ Bridge data structures 

[01 1 5] The function prototype Is: 

5 

void brJbridge_init(voiiO:/^ Initialize Bridge data structures */ 



[0116] This function will initialize the various message queues and semaphores upon which the different tasks rely 
10 for communicating and transferring data. In addition, it will initialize the CPE Table data structures: hash table 1 02, list 
nodes buffers and staclc. 

4.3.2 Set Bridge Operating Parameters 

IS [0117] The function prototype is: 

int brjbridge^set ( bridge^cmd parameter, int value J; 
2Q /* Set a Bridge parameter to desired value */ 

[01 1 8] This APi allows the CM l\/lanager to set a bridge parameter, such as Downstream/Upstream forwarding, to a 
given value. The supported parameters are defined in the enum bridge_cmd. They are: 

BRIDGE_UP Can be set to "true" or "false". 
FORWARDING_ENABLED Can be set to "true" or "false". 

MAX_NUIVIBER_CPE Can take any integral value between 0 and the maximum number of. CPE's supported by 
the DOCSIS' Bridge. This maximum number. issipecif led J^y the constantdeqlaratiori.MAX^ePE (see section 3.4)1 
The returned value is either "true" (the required parameter was set successfulty) or "false" (the required pararheter 
could not be set to the required value). * ' . = ' 

4.33 Provision a CPE IVi AC Address 

[0119] The function prototype Is: 

35 

int br ^provisionjCFE ( a48 address); 
/* Provision a CPE MAC address */ 

[0120] This API allows the CM Manager to provision a CPE MAC Address, following the parsing of the CM Config- 
uration File downloaded through TFTP, The address parameter Is the 48-bit CPE MAC address to provision. The 
returned value is either "true" (the required parameter was set successfully) or "false" (the required parameter could 
not be set to the required value). 

4.4 Bridge interface with CPE Interface Ethernet Controller 

4.4.1 Downstream Ethernet Transmit Interface 

so [0121] The bridge downstream forwarding process 64 needs to transmit Ethernet frames on the CPE Ethernet port 
and, when transmission is not possible immediately because the Ethernet controller is already transmitting a frame, 
queue them for transmission at a later time by the End of Transmission Inten-upt handler or thread. The API for trans- 
mitting a frame on the Ethernet port is: 

void Ether JStart(DwstrJtdr ^DwstrJBuffer); 

/* starts Ethernet transmission of frame in downstrecm buffer */ 



25 o 
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[0122] This routine wiil set the Ethernet controller 54 to transmit the downstream frame passed as a parameter and 
also set the Ethernet Transmission flag: 

volatile boolean Ether_TX_Active: /* transmission active flag */ 

5 

[0123] This flag will be reset by the Ethemet End of Transmission Inten-upt handler or thread. It is used as a "busy" 
signal to the downstream fonvarding process, indicating that a frame is being transmitted and that subsequent frames 
must be queued. 

[01 24] The downstream forwarding process 64 uses a message queue 74 to communicate with the Ethemet controller 
10 54: it copies a pointer to the downstream buffer into it. 



messagejiueue ^Dwstr Fwd Queue = &DwstrJFwd_Q^e^ie_Struct; 
IS /* Downstream Forwarding Message Queue */ 



The Ethemet End of Transmission Inten^upt handler or thread will check this message queue: If there is a downstream 
buffer in the queue. It will immediately start transmitting it. using the Ether_Start() API, and leave the EtherJOC^Active 
20 flag set to "1". If the queue Is empty, It will reset the Ether_TX_Actlve flag and retum. 

[0125] The downstream fonvarding process 64 must put all downstream frames for the CPE Ethernet port into the 
message queue 74, and then check the Ether_TX_Active flag: 

o If it is reset, the message queue is read and, If there is a message Inside, the downstream buffer Is Immediately 

transmitted, using the Ether_Start() API. 
«> If it is set, no action is perfomied: The Ethernet End of Transmission Interrupt handler will check this message 
queue; as indicated before. 

4.4.2 Upstream Ethernet Receive Interface.. 

[0126] Ethernet frames are received on the CPE Ethernet port of the Ethernet controller 54 and copied Into an Up- 
stream buffer 78 from the Upstream buffer pool. Oh the ST20-JEI platform, the upstream buffer is pre-allocated before 
the frame reception and the Ethemet controller 64 copies the received frame into the frame field of that buffer. On the 
Explorer platfonn, the received frame will be copied from the CS8900 memory into the Upstream buffer by the 
enetO_Thread() thread. 

[0127] The Ethernetcontrollerchipmustbe setto "promiscuous mode": it must accept any Ethernet frame, regardless 
of Its destination address. Frame processing and filtering will be perfonned by the Upstream Fonvarding task 82. 
[0128] Upon successful frame reception, during the Ethernet receive ISR (or thread), the Upstream Buffer 78 is 
passed to the Upstream Forwarding task 82 by copying a pointer to the Upstream buffer Into the Upstream Message 
queue 86: 

message^qtieue ^Upstr Fwd Queue = &Upstr_Fwd_Queue_Struci; 
^ /* Upstream Forwarding Message Queue */ 

The Upstream Fonvarding task 82 Is pending on that message queue and wiil process the Upstream frame, and then 
retum the buffer back to the pool. After sending the received frame Into the Upstream Message queue 66, the Ethemet 
receive ISR gets a new Upstream Buffer 78 from the Upstream buffer pool for the next received Ethernet frame. 

50 

5 Bridge Task Partitioning and Process Flow 
5.1 Task Partitioning 

S5^ [0129] The bridge 58 is concurrently runing two separate tasks: the Downstream Forwarding task 64 and the Up- 
stream Forwarding task 82. In parallel the local host receive task 70 is processing the incoming frames destined to the 
CM host 56A, 56B, thus avoiding to tie-up the Downstream bridged traffic while a frame Is being processed up the CM 
host. 
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5^ Downstream Bridging Tasks and Interrupts 

[0130] In the downstream direction, one task will be implemented: the downstream fonwarding task 64. In addition, 
for the ST20-JEI platfomi, two intenupt handlers associated with the Ethernet controller 54 will be used. On the Explorer 
platform, a short ISR, enetOJsrQ and a specific thread, enetOJThreadO will be used 
[0131] Notes: 

1. All details related to the MACE Ethernet Controller chip and its interrupt handlers are specific to the ST20-JEI 
platform. 

2. On the MACE chip, the Transmit and Receive Interrupt share the same inten'upt handler, a checking of the 
Intenupt Status allows to branch to the Rx or Tx part of it, although in the present document, they are described 
as two separate handlers, for clarity purposes. 

3. Similarly, on the Explorer platfomi, the enetOJThreadQ contains sections of code for the downstream forwarding 
task 64, as well as code for the upstream forwarding task 

82. Details for the upstream forwarding part are provided in section 5.3. 

5.2.1 Downstream Forwarding Task 

[01 32] The downstream forwarding task 64 receives the DOCSIS frame buffer, and either discards the frame, passes 
it to the local host receive function 70 or to the Ethernet Transmission queue 74 (see section 1 .2.1). The simplified 
process flow is: 



If Bridge device is hot "Up" 

Continue: Go to next iteration of ''while" loop with same buffer. 

Endlf 

check Ethernet frame Destination Address (DA) 
DoCasefDAJ 

Case: Broadcast 

get a message structure from Fusion message buffers 
If Fusion btsffer available 
Copy frame contents into Fusion message buffer 
Queue message into Fusion inbound queue 




Get buffer from Downstream Buffer pool 
While (true) 
^^^^ ;; invoke CM MAC receive API j^^^ 



Signal Fusion Receive Task Semaphore 
Endlf 
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If Forwarding_Enabled 
formgrding^decision = Forward to Ethernet 
Else 

forwarding decision = Discard 

End If 

break 

Case: Multicast 

If DA == CM MAC Management frame 
fonvarcRngjiecision = Discard 
Else 

get a message structure from Fusion message buffers 
If Fusion buffer mailable 

^^py frame contents into Fusion message buffer 
Queue message. into Fusion inbotmd queue 
Signal Fusion Receive Task Semaphore 

' End^jf - -y: -x^-r^^^ 'v -^ • 

V ilfForwardbig^Enabled 

Forwarding_decision - Forward to Ethernet 
Else 

Forwarding_decision = Discard 
Endlf 

Endlf 
Break 

Case: Unicast, addressed to CM IP host 
forwardingjdecision = CMJSost 
break 

Case: Unicast, NOT addressed to CM IP host 
IfForwarding^Enabled 

Get exclusive access to CPEJTable 

Search CPEJTable for DA 
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If Found AND Stqjported TRUE 

forwardingjiecision ^ Forward to Ethernet 

Else 

forwardingjiecision - Discard 

End If 

Release exclusive access to CPE Table 

Else 

forwarding^decision = Discard 

Endlf 
break 
End Case 

DoCase [forwardingjlecisionj 
Case: Discard 

Break (will reuse the same bt^er for the next Downstream frame). 
Case: Forward to Ethernet . 
Queue Dowmtream Buffer irito Downstr^ 
If No Ethernet Transmission Ongoing ; 

If there is a message in Downstream: Forwarding queue 

Read message queue, get Downstream buffer pointer 

Release message. 

Start Ethernet Frame transmission 

Endlf 

Endlf 

Get a new Downstream bt^rfrom Downstream Buffer pool 
break 

Case CMJIost: 

Queue Downstream Buffer into Downstream Fusion queue. 
Get a new Downstream buffer from Downstream Buffer pool 
break 
End Case 
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EndWhile 

5.2.2 Ethernet Controller Transmit Interrupts 

[0133] The following two interrupts complete the downstream fonvarding task, on the ST20-JEI platfomi: 

• MACE Interrupt (Transmission complete) 

• Transmit FIFO Empty 

[0134] The simplified process flows are: 

[0135] MACE Interrupt (Transmission complete): 

Disable Transmit FIFO Empty Intemipt 

Return Downstream btiffer back to Downstream Buffer pool 

If there is a message in Downstream Forwarding queue 

Read message queue, get Downstream buffer pointer. 

Release message. 

Start Ethernet Frame transmission 
Endlf • • - 

Dismiss Interrupt /«:..-'.-vVo ;-■ 'v-;;' 

On the Explorer platfomi, a similar process flow Is perfomied In the relevant "case" of the enetO__Thread(), 
[0136] Transmit FIFO Empty: " 

If more than 64 bytes left to transmit 

Copy 64 bytes (32 16'bit words) to Tx FIFO 

Else 

Copy remaining number of bytes to Tx FIFO 
Disable TransmU FIFO Enq>ty Interrupt 

Endlf 

Dismiss Interrupt 
BJS Upstream Bridging Tasks and Interrupts 

[0137] In the Upstream direction, forbridged traffic (from the Ethernet controller 54), one Upstream Fonvarding task 
82 will be Implemented. In addition, for the ST20nJEI platfomi, two Interrupt handlers associated with the Ethernet 
controller (MACE) are part of that process. 

[0138] For the CM Host 56A, the local host transmit routine (bridge_start()) will be called by the Fusion task device 
sending routine: ndq^start. It will operate in the original Fusion application task context and transmit the frame directly 
to the Upstream CM MAC driver, as described in section 5.5. 

[0139] Note: On the MACE chip, the Transmit and Receive inten-upt share the same Interrupt handler, a checking of 
the Intenupt Status allows to branch to the Rx or Tx part of it, although in the present document, they are described 
as two separate handlers, for clarity purposes. On the Explorer platfomn. this Is one "case" of the eneW_Thread(y. 
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5.3.1 Upstream Forwarding Task 

[0140] The upstream forwarding process 82 operates on frame received from the Ethernet controller 54 and either 
discards them or forwards them to the CM MAC 52. The simplified process flow Is: 



While (true) 

wait for Upstream Forwarding message queue from Ethernet Sx Intempt 

read message from queue, get Upstream buffer pointer 

release Upstream Forwarding message 

jy Bridge device is not "Up" 

Return Upstream buffer to Upstream Buffer pool 
Continue: Go to next iteration of "while " loop. 

End If 

check Ethernet frame Destination Address (DA) 
DoCase[DA] 

Case: Broadcast 
ifForwarding_Enabled 

forwaf'dingjlecisidn = Forward to CM MAC 
Get exclusive access to CPE_Table 
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Search CPEJTable for Ethernet frame SA (Source Address) 
If i^at Found) 

If Nvmher of supported CPE Less Than Max 
allowed CPE's 

Add CPE's SA to Table as Supported and 

Learned 

Else (Max number of allowed CPE's reached) 

Add CPE's SA to Table as NOT Stq?ported 

Endlf 

Endlf 

Release exclusive access to CPEJTable 
Else (Forwarding not enabled) 

forwardingjiecision = Discard 

Endlf 
Break 

Case: Multicast 

If DA Bridge Protocol Data VnitBPDU 
forwardingjdecision - Discard 

Else 

IfForwarding_Enabled 

forwardingjkcision = Forward to CM MAC 

Get exclusive access to CPEJTable 

Search CPEJTable for Ethernet frame SA (Source 

Address) 

If(NotFowicO 

If Number of supported CPE Less Than Max 

allowed 

Add CPE's SA to Table as Supported 

and Learned 
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Else (Max number of allowed CPE's 

reachecQ 

Add CPE's SA to Table as NOT 

Stpported 

Endlf 

End If 

Release exclusive access to CPEJTable 
Else (Forwarding not enablecQ 

forwardingjdecision = Discard 

Endlf 

Endlf 
Break 

Case: Unicast 

If Forwarding JEnabled 

Get exclusive access to CPE_Table 

Search CPEJTable for Ethernet frame SA (Source Address) 
If Found 

If Supported TRUE 

Search CPEJTable for DA (Destination 

Address) 

If Found 

Jbrwcrding^decision = Discard 

Else 

forwarding jlecision = Forward to 

CMMAC 

Endlf 
Else (Not Supported) 

forwardingjiecision = Discard 

Endlf 
Else (Not Found) 
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If Number of supported CPE Less Than Max 
allowed CPE s 

Add CPE's SA to Table as Supported and 

Learned 

Search CPEJ'able for DA (Destination 

Address) 

If Found 

forwardingjiecision = Discard 

Else 

forwardingjiecision = Forward to 

CMMAC 

Endlf 

Else (Max number of allowed CPE 's reached) 

Add CPE 's SA to Table as NOT Stpported 
' Jbrwardingjkcisibh = Discard 
End lf r 

Endlf 

Release exclusive access to CPEJTable 
Else (Forwarding not enable^} 

forwcwdingjiecision = Discard 

Endlf 
End Case 

DoCase [forwardingjiecision] 
Case: Discard 

Return Upstream buffer to Upstream Buffer pool 
break 

Case: Forward to CMMAC 

Send Upstream buffer to DOCSIS driver send API. 

Return Upstream buffer to Upstream Buffer pool 

break 
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End Case 
End While 

5.3.2 Ethernet Controller Receive Interrupts 

[0141] On ST20-JEI platfomi, the following two interrupts are also part of the upstream fonvarding process 82: 

• MACE Interrupt (Frame Received) 

• Receive FIFO Full 

[0142] The simplified process flows are: 
[0143] MACE Intenxipt (Frame Received): 

Send Upstream buffer pointer to Upstream Forwarding message queue. 
Get new Upstream buffer from Upstream Forwarding Buffer pool 
Point MACE to start of Ethernet frame in Upstream buffer. 
Dismiss Interrupt 

Note: Upstream Buffer for the first frame is pre-allocated by the MACE Init routine. 
[0144] Receive FIFO Full: . . ; 

Copy 64 bytes (32 16-bit words) to current Upstream Buffer 
Dismiss Interrupt 

On the Explorer platform, a similar process flow is perfomried in the relevant "case" of the enetO_Thread(). 
5.4 Local Host Receive Task 

[0145] The local host receive task 70 is activated by the downstream forwarding task 64 through the local host receive 
task message queue. The simplified process flow is: 

While (true) 

Wait for Fusion Receive Task Message Queue 
If LLC Header 
Process LLC Command 
Else 

ff' Fusion message available from Fusion LWQ queue 

. Copy Downstream Ethernet frame into Fusion message 
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Queue message into Fusion LWQ queue 
Call Fusion receive routine (Iwq^recy^taskQJ 
Return Downstream Buffer to Downstream buffer pool 

Endif 

Endif 
End While 

>.»>--.. 

5.5 Local Host TVannistt Routine 

[0146] The local host transmit routine is brfdge^startQ at the end of Fusion Transmit calling tree. The simplified 
process flow Is: 

Get new buffer from the dedicated Fusion Upstream buffer pool 
y Upstream btiffer mailable 

Copy Length from Fusion message to Upstream buffer 

Set Service Type in Upstream buffer (0 for now) 
':^kh Copy Ethernet frame from Fusion message to Upstream buffer 

Send Upstream buffer to DOCSIS driver send API. 

Return Upstream buffer to Upstream Buffer pool, 

Endif 

5.6 IEEE 802.2 LLC Processing 

[0147] As stated above, the cable modem 50 includes an LLC host 56B. As such, the CM responds appropriately to 
TEST and XID requests. The XID and TEST requests can be sent over IEEE 802.3 formatted frames only. Incoming 
frames using that format can be flagged by analyzing the 1 6-bit field that comes immediately after the Ethernet source 
address: for DIX framing, this is the "Ethernet Type", whose value is 2048 (0x800) for IP carrying frames, 2066 (0x806) 
for ARP. etc. If that 1 6-bit field value is equal or less than 1500 , most likely the frame is an IEEE 802.3 (LLC) fonnatted 
frame and that 1 6-bit field is actually the 802.3 "length" field. Downstream frames from the CM MAC 62 whose desti- 
nation address matches the CM MAC address and with an "Ethernet Type" value less or equal than 1500, will be 
passed to the LLC host 56B for further processing. 

6 Procedural Design 

6.1 Downstream Forwarding Procedures 

6.1.1 Downstream Forwarding Task 

[0148] Function Prototype: 
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static void Dwstr__Fwdjrask (void *p); /"^Downstream Forwarding V 
Task Internal Data Structures:. 

taskjcb Dwstr FwdJTaskjrCB; /* TgskControl Block V 
taskjtesc Dwstr^wdJTaskJ>esc; /♦ Task Descriptor ♦/ 
Inter-Task Communication: 

message_queue *DwstrJwd jQueue^ &Dwstr_Fwd J2ueueJStruct; 
/* Downstream Forwarding Message Queue V 
Note: message size is 4 bytes (1 pointer). 

message_queue Fusion RX Queue: 
/* Fusion Receive Task message queue */ 
volatile boolean Ether^TX_Active- false; 
/* Ethernet transmission active flag */ 

oswjnutexj CPEJTableJSem; /* CPE Table Access Semaphore */ 
Local Variables: 

Dwstr jtdr "^Dwstr Buffer;/* Downstream DOCSIS frame ♦/ 
int Dwstr error; /* Error code returned by CM MAC */ 
A£ACjaddr*CFEJSntry;/* CPE Table Entry */ 
ether Jieader * Hdr_Ptr; /* pointer to Ethernet header ♦/ 
enum EthJFrame_Type Frame _Type; /* Frame type classifier V 
enum FwdJDecision Forwarding; /* Frame Forwarding decision */ 
message J}uffer Dwstr_Msg; /* temporary storage for Dwstr msg. V 
messagejbuffer *Dwstr_Ptr = iScDwstr_Msg; /* message pointer ♦/ 
Static and Global Variables: 

boolean Bridge JUp ^ false; /♦ true if bridge interface is up */ 
boolean ForwardingJEnabled = false; /* true if enabled V 
HashTable CPEJTable; /* CPE MAC Address Table V 
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int MaxJStq?portedjCPE = MAXjCPE; 
/* Maximum number of supported CPE set by CM Manager / 
^ int SupportedJZPE = 0; /* Total number of supported CPE V 

ini Learned JZPE = 0; /* Total number of learned CPE V 
Stack tJDwstr Pool; 

/♦ Downstream Buf^s Pool Control Structure */ 

stt^c void *Dwstr_PtrJ»ackfMAX_pWSTRJ; 
IS /* Downstream Buffers Pointers Stack */ 

static Dwstrjuir Dwstr^iff_Array[MAXJ>WSTR]; 

/* Downstream Buffers Array ♦/ 
^ Process flow: See Section 52,. 1 

Ancillary Functions called: 

boolean Compare JAAC^Addr ( a48 addrl, a48 addrl); 

25 

- ' /* returns true if both MAC addresses are equal V 
static boolean Is_MAC_Mdnagement( a48 addr); 
/* returns true if MAC address is CM MAC Management */ 

30 

- MAC_addr ^SearchjCPE\Table(a48 addr, HashTable *Table); 

/* Search CPE Table for this address */ 
33 void Dwstr_FusionJtX(DwstrJuir *DwstrJ3uffer); 

/* Copy frame inside DOCSIS buff into Fusion Message */ 

void Process JLLCjOmd(DwstrJtdr *Dwstr_Buffer); 
40 /* Process received LLC command */ 

void Ether JStart (Dwstrjuir *Dwstr_Buffer); 

/* starts Ethernet transmission of frame inside DOCSIS buff*/ 

45 

6.1.2 Ethernet Tkransmit Interrupts 

[01 49] The MACE Ethernet controller will generate an Interrupt when a frame is received or a frame transmission is 
complete: 

so 

void Macelnterrupt (void}; 

[0150] The MACE flags are checked, If it is a transmit Interrupt, the corresponding process flow Is executed. 
[0151] Inter-Taslc Communication: 
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volatile boolean EtherJXjictiye- false: 

Ethernet transmission active flag V 
Local Variables: 
int xmtStat; transmit status V 
int in^tat; 
tntretryStat; 
int retryCount: 
Static and Global VariiAles: 
Stack J Dwstr_Pool; 

/♦ Downstream Bikers Pool Control Structure V 

Process flow: See Sectkm 5^.2 

Ancillaiy Functions called: 

void Ether_Start (D)^trjidr *I>wstr_Buffer); 

/* starts Ethernet transmission offrhme inside DOCSIS buff */ 

In addition, .the MACE Transmit FIFO will generate an interrupt request: 
void TDTinterrupt (void; . ; :- : • 

6^ Upstream Forwarding Procedures . : 

6.2.1 Upstream Forwarding Task 

[0152] Function Prototype: 

static void UpstrJFwdJTask (void *p) /♦ Upstream Forwarding */ 
Task Internal Data Structures: 

taskjcb Upstr^FwdJ'askjrCB; /* Task Control Block ♦/ 
task_desc Upstr^FwdJTaskJDesc; /* Task Descriptor */ 
Inter-Task Communication: 

message jiueue *Upstr Fwd Queues AUpstr Fwd _^ueueJStruct; 
/* Upstream Forwarding Message Queue */ 
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osw mutexj CPEJTableJSem; /* CPE Table Access Semcq^hore V 
Upstr_error = docsi5drv^miPdu( ServiceJType, UpstrJBuff'>frame, 
Upstr_Bt^'>len): 

Local Variables: 

mt ServiceJType = 0; /* DOCSIS Service Type (0 by default) */ 
MACjiddr *CPEJ£ntry;/^ CPE T^ intry V 
ether Jteader ♦ Hdr_Ptr; pointer to Ethernet header */ 
enum Eth_FrameJType Frame _Type; /* Frame type classifier */ 
enum Fwd_Decision Forwarding; /♦ Frame Forwarding decision V 
Vpstrjxdr ^Upstr^itff; /♦ Upstream message buffer */ 
• message Jbuffer *A£sg_Ptr; 

/* Pointer to Upstream message from Upstream Forwarding Queue V 
ha Upstr_error; /* Error code from DOCSIS <biver API */ 
Static and Global Variables: 

boolean Bridge JJp = fidse; /♦ true if bridge interface is up ♦/ 
V *; boolecui Forw€P^€ting_Enabled= false; /* 

HashTia>leCPEJ'able;/*CPEmCAddressTableV 
im Max_SupportedjOPE ^MAXJOPE; 

/♦ Maximum number of supported CPE set by CM Manager V 
int SupportedjCPE = 0; /* Total number ofsi^ported CPE */ 
irU Learned JCPE = 0; /* Total number of learned CPE V 
Stack J Upstr_Bri_Pool; 

/* Upstream Bridging Buffers Pool Control Structure ♦/ 

static void *UpstrjBri_Ptr_Stack[MAXJBRIJJPSTRJ; 

/* Upstream Bridging Bikers Pointers Stack V 

static Upstrjtdr Upstr_Bri_BuffjirrcyPMX_BRIJJPSTR]; 

/* Upstream Bridging Buffers Array V 

Process flow: See Section 53.1 

Ancillary Functions called: 

boolean Compare^MAC^Adcb' (a48 addrl, a48 addr2); 
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/♦ returns true if both MAC addresses are equal */ 
static boolean Ls^BPDU (a48 addr ); 

/* returns true if MAC address is Bridge Protocol DcUa Unit */ 
mCjiddr *SearchjCFEjrable(a48 addr, HashTable *Table); 

Search CPE Table for thisfuldress ♦/ 

* *" ■ —^jg^'-i 

static void Leant CPE ( a48 addr ); 
/* Learn this CPE if allowed */ 
intAddjCPEjrable(a48 addr, 
u8 Supported, 
u8 Provisioned, 
HashTable *Table); 

/* Add a CPE to the CPE M4C Address Table*/ 
6.2.2 Ethernet Receive Interrupts 

[0153] . The MACE Ethernet controller will generate an interrupt when a frame is received or a frame transmission is 
compieteiv:' ' ..... ........ 

void Macelnterrupt (void); Note this js the same Interrupt routine for recei9tion,ahd for end of transmission. The 
MACE flags are checked, If it is a receive interrupt, the corresponding process flow Is executed. 
[0154] Inter-Task Communication: 

message queue *Upstr Fwd Queue= &UpstrJ^wd Queue Struct; 

/* Upstream Forwarding Message Queue */ 

Local Variables: 

int rcvStat; /* receive status */ 

int ten; /* received frame length */ 

int dummy; /* temporary H/W register copy */ 

Upstrjidr *Upstr_Buff; /* Upstream message buffer */ 

Static and Global Variables: 

static volatile boolean discardThisPacket; 

/* Discard Ethernet frames flag V 
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static char discardBuffgr[2048]; 

/* "trash" bt^er for discardedframes V 

static M4CEJPRAM *dv; 

/^pointer to MdCE Ethernet Controller H/W registers ♦/ 

static volatile char *maceRecvBvffer; 

/♦ Buffer M4CE Ethernet Controller isreceiving into V 

static volatile int maceRecvLen-0; 

/* Received bytes counter ♦/ 

Ptocess flow: See Section S3.2 

Ancillary Functions called: None. 

In addition, the MACE Receive FIFO will generate an intemipt request: 
void RDTIntemqjt (void}; 

6.3 Local Host Receive Task 

[0155] This task actually starts Fusion message state, machine upon reception of a.frame from the downstream. 

forwarding task 64. 

[0156] Function Prototype: 

static void Fusion_RX_Task (void *p): /* Fusion Receive task */ 
Task Internal Data Structures: 

taskjcb FusionJtXJTaskjrCB; /* Task Control Block */ 

task_desc Fusion JtXjrask_pesc; /* Task Descriptor */ 

Inter-Task Communication: 

message^queue Fusion RX Queue: 

/* Fusion Receive Task message queue V 

Local Variables: None. Static Variables: None. Process flow: See Section 5.4 

6.4 Fusion Bridge Device Procedures 

[0157] These procedures are part of the bridge 58 as seen from the Fusion protocol stack: see Fusion Porting Guide 
and section 4.2.2. 

6.4.1 Bridge TVansmlssion Start Procedure 
[0158] Function Prototype: 
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im bridge_start(m ♦ mp); 

Inter-Task Communication: 

Upstr_error = docsisAv^ruiPdu( Service JType, 

UpstrJBuff->frame, 

Upstr_Buff'>lefi); 

Static and Global Variables: 

static Stack J UpstrSMJPool: 

/♦ Upstream Fusion Buffers Pool Control Structure */ 
'Local Variables: 

int Service JType = 0; /* DOCSIS Service Type (0 by default) ♦/ 
Upstrjtdr ^UpstrJSuff; /* Upstream message buffer V 
Process flow: See Section S.S 

6.4.2 Bridge Initialization Procedure 
[0159] Function Prototype: 

int bridge_init(netdev * n^); 
[0160] Static and Global Variables: Process flow: 

Initialize Fusion data structure (local Jhs_dataO) with CM MAC address. 

Initialize and Start Fusion Receive Task 

Initialize Ethernet controller (Tx and Rx are disabled). 

Initialize and Stwt Downstream Forwarding Task 

Initialize and Start Upstream Forwarding Task.. 

6.4.3 Bridge Up/Down Procedure 
[0161] Function Prototype: 

int bridge^pdown(netdev ♦ ndp, uI6 flags, char * options); 
[01 62] Static and Giobai Variables: 

boolean Bridge JUp ^ false; true if bridge interface is up ♦/ 
[0163] Process flow: 
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If flags value is: Up (true) 

Initialize Link Layer structure of Fusion Network Device Data Structure, 

Enable Ethernet Controller frame reception and Internets. 

Allocate buffer pool from Fusion LWQ heap. 

Enable Data transfer between CM MAC and CM IP host (Fusion), 

Else fflags value is: Down (false)) 

Release Fusion LWQ buffer pool 

Disable Ethernet Controller frame reception and Intemqjts. 
Disable Data transfer between CM MAC and CM IP host (Fusion). 
Disable Data forwarding between CM MAC and CPE Ethernet port. 
Endlf 

6.4.4 Bridge Input/Output Control 
[0164] Function Prototype: 

int bridge_ioctl(netdev * nc^, intcmnd, chixr * addr): 
[0165] Static and Global Variables: Process flow; 

DoCase [cmnd] 

Case ENIOCNORMAL: 
Return Code: No Error 
break 
default: 

Return Code: Not Stq?ported 
EndCase 

Note: This function is implemented for compatibility with Fusion Network Device Interface only; it does not perfonn any 
action regarding the operation of the bridge 58. 

7 DOCSIS Bridge File Structure 

7.1 Implementation Files 

[0166] The DOCSIS Bridge implementation code will be in the following files: 
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1. bridgecnLc (Downstream and Upstxeam Forwarding) 
^ DwstrJFwdJTaskO /* Downstream Forwarding Task ♦/ 

Upstr_Fwd_ProcO /* Upstream Forwarding Task ♦/ 
Compare JAAC^AddrO /* Compares 2 MAC addresses ♦/ 
*o Is^MACJdanagememO /* check if frame is MAC Management */ 

Is^BPDUO^ check if Bridge Protocoipqta Unit ♦/ 
LeamjOPEQ/* Learn a CPE (if allowed} ♦/ 
InitJBrtdge_Bug^O /* /«// Aru/ge J}i{^r /foo/s ♦/ 
Init Bridjge QueuesO /* JhiV Bridge message queues V 
Start_BridgeO /* 5>Wge Startup routine */ 

2. macejbrix (MACE Ethernet Controller Interface: on the JEI platform only) 
MaceIntemq}tO /* MACE controller internet handler */ 
TDTInterruptO /* Ji /vZFO intemq>t handler ♦/ 
RDTIntemq>tO/*Rx FIFO interrupt handler y 

''V^i 4- Ether JnitQ /* Ethernet controller 

30 Ether JJpDownQ /* Ethernet controller enable routine */ 

Ether_StartO /* Ethernet controller transmit routine */ 

Ether JoCtlQ /♦ Ethernet controller control routine */ 
^ EnableEtherlntemq^O /* A4<CE intemq^ts enable */ 

DisableEtherfnterruptsO/* MACE intemq}ts disable V 

InstalllnterruptsO ^ MACE interrupts setiq) V 

3. enetj)ri.c (CS890O Ethernet Controller Inter&ce: Explorer platform only) 
Ether JnitO /* Ethernet controller WW init routine ♦/ 

Ether JJpDownO /* Ethernet controller enable routine V 
EtherJStartO /* Ethernet controller transmit routine */ 
Ether JoCtlQ /* Ethernet controller control routine ♦/ 
50 enetO^ThreadO /* Interrtq^t processing thread ♦/ 

4. bridgedv.c (DOCSIS Bridge Fusion Network Device Interface) 
bridge JnitQ /♦ Fusion Network Device Init */ 

bridge jq>downO /* Fusion Network Device Rx/Tx enable ♦/ 
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bridge _stixrtO /* Fusion Network Device transmit start */ 
bridge JoctlO /* Fusion Network Device Control */ 
Fusion JtX JTaskO /* Fusion IP Protocol Stack receive task V 
Dwstr_Fusion_RXO/* Fusion Downstream Receive routine V 
IfdtJJpstrJ^usion^vffersQfZ ^"'^ Fusion Buffers pool */ 

5. mncs^llcc (802.2 LLC processing code) 
Process_LLCJZmdO /» Process received 802,2 LLC command V 

6. qx^tablex (CPE MAC Address Table processing) 
JnitJCPEJTableO /* Initialize CPE Table Data Structures */ 
SearchjCPEJTableO /* Search CPE Table for a MAC address ♦/ 
AddjCPEJTableO /*Adda CPE to CPE MAC Address Table */ 
Remove^LeamedjCPEQ/* Remove learned CPE from CPE Table */ 

7. bridge_if.c (Bridge Inter&ce with Cable Modem Manager) 
brJbridgeJnitO /* Initialize Bridge data structures */ 

, brJ}ridge_setO /* Set Bridge parameter to desired v^^^ 
br^ovisionJZPEO f* Provision a CPE MAC adiSress^/ ' 

8. bufifers.c (Stack based Memory Objects Management) 
Init_StackO /* Initialize Stack control structures V 
GetjObjectO /* Get new object from stack */ 
RetumjObjectQ /♦ Return an object back to stack */ 

7J2 Header Files 

[0167] The headerflles allow the bridge implementation code to share data structures and function prototypes. The 
file bn'dgedv.c includes all of the Fusion headers plus some specific headers for Interface with the bridge 58. The CM 
MAC software will also share some headerflles with the bridge software. 

bridge.h DOCSIS Bridge private headers 

Included by: 

brid^cm.c 

macejbri. c (JEI platform) 
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enetj>ri.c (Esqflorer platform) 
brtdgejfc 

bridgecnkk DOCSIS Bridge Inter&ce headers 
Included by: 

bridgecntc . 

maeejbri.c (JEI platform) 

enetjbric (Explorer platform) 

bridgedvx 

bridge Jfx 

CM MAC Software 

mcnsJfM DOCSIS Bridge/MAC Interfice headers 
Included by: 

bridgecm^c ' ~ < / . . : 

CM MAC Sofivyare 

Ftisiofum.h DOCSIS Bridge/Fu^on Inter&ce headers 

Included by: 

bridgeofLC 

bridgedv.c 

ether J}rLh DOCSIS Bridge/Ediemet Controller Interfoce headers 

Included by: 

bridgficm,c 

macejbrix (JEI platform) 
enetJbrLc (Explorer platform) 

ether Jfh Function Prototypes for Ethernet Control Routines 
Included by: 
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macejbrtc (JEI platform) 
eneijbri.c (Explorer piatform) 
bridged^, c 

mcnsjlch 
Included by: 
mcns_llc.c 
bridgecnLc 

hashh Hash Table headers 

hicluded by: 

bridgecm,c 

cpe_Jable.c 

bridge jf,c 

&rfdr^e_iX/r Btidge and CM Manager Inter& 

Included by: 

bridgecm.c 

cpe_table.c 

bridge _ifc 

[0168] The above description of illustrated embodiments Is not intended to be exhaustive or to limit the Invention to 
the precise fomis disclosed. Accordingly, the invention is not limited by the disclosure, but instead the scope of the 
invention is to be determined entirely by the following claims, which are to be construed In accordance with established 
doctrines of claim interpretation. 

Claims 

1 . A cable modem link layer bridge, comprising: 

a downstream forwarding task structured to receive a first message from a cable network and fonvard the first 
message to a customer premises equipment (CPE); and 

an upstream forwarding task structured to receive a second message from the CPE and fonward the second 
message to the cable network, the upstream and downstream fonwarding tasks being multitasked such that 
the second message is fonwarded by the upstream forward task while the first message Is being forwarded 
by the downstream fonvarding task. 

2. A cable modem link layer bridge, comprising: 

a station cache that includes a plurality of station entries, each station entry being associated with a respective 



802.2 LLC Inter&ce headers 
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one of a plurality of customer premises equipment (CPE), tfie station entry including a function identifier tliat 
identifies an action to be taken by the bridge In response to receiving a message intended for tfie associated 
CPE; and 

a station cache manager structured to modify the function identifier in response to a user request. 

A cable modem, comprising: 

a host for receiving messages directed to the cable modem; 
a first set of memory buffers for storing messages; 

a media access controller (MAC) structured to receive a first message from a cable network and store the first 
message In a first memory buffer of the first set 

a downstream forwarding task structured to determine whether the first message is directed to the host; 
a second set of memory buffers; 

a host receive task structured to copy the first message into a second memory buffer of the second set, release 
the first memory buffer for re-use by the MAC, and pass control of the first message to the host for processing 
using the second memory buffer. 
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